Four Keys

DevOps Research and Assessment（DORA）チームが実施した 6 年間の研究から、ソフトウェア開発チームのパフォーマンスを示す 4 つの指標が確立されました。

デプロイの頻度 - 組織による正常な本番環境へのリリースの頻度

変更のリードタイム - commit から本番環境稼働までの所要時間

変更障害率 - デプロイが原因で本番環境で障害が発生する割合（%）

サービス復元時間 - 組織が本番環境での障害から回復するのにかかる時間

モバイルアプリというリリース頻度が増えすぎるとユーザー体験を損ねる世界

時期によっては「しばらく全くリリースしない」もある

→リリース頻度によらない指標がほしい

生産性指標という呼び方に統一します。

生産性というのは単位あたりの生産量のことですが、今回の文章では単位量が時間、計測対象はEightアプリ開発チームで確定しています。そのためチームの時間あたりの生産量、つまりチームの生産性を計測していることになるからです。

four keysの3観点をベースに構築しなおして、こうした

スループット

プロダクトバックログアイテムの完了数

完了したプロダクトバックログアイテムのポイント数合計

プルリクのマージ数

リードタイム

プロダクトバックログアイテム着手から完了までにかかったスプリント数の平均値

プルリクのマージ時間の平均値

品質

QAの不具合数

hotfixリリースの数

思想

いずれもリリース頻度には依存しない値になっています。

Four Keysはリリース頻度が強い影響を持つ指標になっています。……一方でモバイルアプリでは、Webと比べて過度にリリース頻度を増やすとユーザ体験を損ねる場合があります。もちろん毎日アップデート申請すること自体は可能です。しかしユーザから見るとアップデートの通知もダウンロードも毎日発生するアプリになってしまいます。

測定したいのは同じチームの成長につながっているかどうかであること、見積もりの基準を明確化することで、意図的な水増しをある程度防げることから、今回はポイント数が適切と判断しました。

2つあるよ

デリバリのパフォーマンスを測る指標

組織のパフォーマンスを評価する先行指標

しかし「LeanとDevOpsの科学」にもあるとおり、この観点での Four Keys はDORAの研究結果のごく一部でしかありません。もしこの立場でFour Keysを利用するなら、DORAが発見した20以上のケイパビリティ（あるいはDORAモデル）とセットで考える必要があります。僕がスクフェス福岡で話したのはあくまでこの立場に則ったものです。

DORAが広げたこっちの応用例も巷には広まっている

「アジャイル」も原典や具体的な方法論は存在するけど、実際はもっとラフに捉えられてることも多いよね